1. Field of the Invention
The present invention relates to the field of visual programming and more particularly to the generation of form data files which define electronic forms using such a technology.
2. Description of the Related Art
Computers have proliferated into all aspects of society and are instrumental in the running of both businesses and academic institutions. The home personal computer (PC) has now become the norm and the last few years has seen the advent of increasingly cheaper desktop machines, with greater processing power, memory and storage space. Such advances have been essential to keep pace with the new generation of power-hungry applications currently infiltrating the market-place.
Software has changed quite dramatically in recent years. Command-line and text-based packages, which were at one time common-place, are now paling into insignificance. The consumer is placing increasing demands upon the software developers to invent ever better and more functional tools. The old-style products are now invariably considered unacceptable.
Presentation especially is deemed extremely important in the battle to win over the market. Developers invest a great deal of time and effort in constructing user-friendly and aesthetically pleasing graphical user interfaces (GUIs). The Microsoft Corporation has been particularly successful with Windows 3.1, 95 and 98 and their suite of related products. Indeed a defacto standard has been established, such that a large proportion of PC packages are now Windows-based.
Programming methods have also had to change in order to create these new-style applications. Using the traditional model, an application is created, in one of the well-known text-based languages such As C or COBOL, from a number of components or modules. These contain both the presentation and the business logic. These programs are however restricted in the amount of presentation flexibility that they provide to the user.
The industry has recently invested many millions in the creation of new and more sophisticated programming tools which create traditional style applications, but using a visual environment. Such tools have changed the face of programming. It is now possible to develop complex programs using graphics, icons, animation etc. Such a technique is extremely powerful, since it permits the graphical representation of the programming process.
Recently, the Java Programming language, available from Sun Microsystems, has risen to prominence. Java is a platform-independent, object-orientated language, with client/server functionality. It supports concurrency, enabling “real world” objects to do their work simultaneously. Java Beans describe the Java objects which are suitable for use in a visual development environment. Recently many sophisticated visual programming environments have been developed to support the Java component model of Java Beans. These tools are the state of the art and are able to exploit the great flexibility and platform independence of Java and Java Beans. One of these is the IBM VisualAge for Java product. Further information about the Java programming language may be obtained from “Teach Yourself Java in 21 days” by Laura Lemay and Charles Perkins (Sama.net Publishing, Indianapolis, USA, 1996) and “Simple Solutions, Essential Skills—Using Java 1.2” by Mike Morgan (published by Que, ISBN—0-7897-1627-5). Http://java.sun.com also provides a good source of information.
Today applications are created, by assembly, from a range of software components and indeed programmer productivity has been greatly increased through the use of software componentry. FIG. 1 illustrates a conceptual overview of this process. The components 105 may be provided by different vendors and are assembled with any necessary “glue” code (not shown) using a sophisticated visual programming environment running on a development workstation 110. Within the context of Java, it is the Java Beans which provide this functionality.
The result of the assembly process is a compiled, packaged executable program 120 which may be installed into an execution environment on the production system 130 and executed. The application usually deals with all aspects of user interface or presentation and business logic and is thus either a self-contained entity or closely related to other such applications.
Work on speech and other technologies using natural language understanding (NLU) as an interface to applications has created a yet further model for program execution. The next generation of user interface applications will, in all likelihood, be based around NLU and Dialogue Management (DM) technology and will provide significantly more flexibility to the user.
A Dialogue Manager directs the conversation between a human user and a machine. Based upon the user's response to a prompt for input, the Dialogue Manager decides when and how to carry out various business transactions.
Furthermore, it keeps track of the point that the user has reached in the current, and possibly other nested transactions, determining what to present to the user next and how to present results and/or prompt for additional input.
Dependant upon the capabilities of the system, this conversation may be entirely text-based or may take the form of speech. With the latter, the system interprets the speech using NLU techniques. It breaks each sentence down into a string of words, eliminating noise words such as “I”, “and”, “sit” etc., and infers the meaning of the remaining nouns, adjectives and verbs according to the context in which they occur. The ViaVoice speech recognition software, available from the IBM Corporation, is one example of a product which incorporates a Dialogue Manager with NLU functionality.
With this new model of application development, the application is not completely programmed or assembled from software components. The current range of “programming” tools are thus largely inappropriate. These new applications will require new ways of defining programs. Often these programs are defined in terms of “forms”, akin to the paper forms used in business today, and the relationships between these forms. FIG. 2 illustrates a typical “paper” form. This is a somewhat trivialised example which requires the user to provide just two pieces of information:
i) The name of the stock q1; and
ii) The number of shares required q2
In reality business forms invariably require vast amounts of information from the user and often have inadequate instructions and navigational hints.
The new-style applications are created as a set of electronic “forms”, which are then used by a Dialogue Manager to decide when and how to carry out business transactions and how to prompt the user for further input. The forms also define the possible navigational paths through individual transactions and the application set as a whole. Much of the application logic is automated or hidden behind dialogue management software which acts on the form definitions and drives the user interface.
A possible use for the DM technology is a catalogue ordering facility in which a user's query is handled on an entirely automated basis by a computer telephony system/an interactive voice response system (IVR) with added DM functionality. An example of such a system is the DirectTalk for AIX product available from the IBM Corporation.
When a user/customer places a call with the IVR, the system might play a header message asking the customer what action they wish to proceed with. The IVR also supports NLU and can therefore accept a speech-based response. The client might say for example:
“I would like to order a red shirt in a size 12 please”.
The NL software would break this sentence down into a series of separate words, thus ending up with the following list: I, would, like, to, order, a, red, shirt, in, a, size, 12, please
It would disregard all the noise words, but be programmed to realise that “red” was both an adjective and a colour and that since the noun “shirt” proceeded it, it was likely that this the two were related in some way. Furthermore, it would recognize from the context of the sentence that the number “12” was most probably a size. In this way it would try to gain an understanding as to what it was that the user was requesting.
The Dialogue Manager would then proceed through its current form set, filling in as many fields as possible from the speech input provided by the customer. Each form would rated, with the one missing the least information, scoring highest. In this case the “order form” would score best and the system would deduce from this that the customer was trying to order an item from its catalogue.
The Dialogue Manager would then scour the order form for missing information. In the above example it is not clear whether a lady's or a man's shirt is required. Each “form” contains cues to allow prompting of the user for data, plus linkages to the business objects of the system to execute business transactions. The system would therefore ask this very specific query of the user and this may involve playing the appropriate voice segment down the telephone line.
The forms that the Dialogue Manager interprets need to be defined and these definitions are often created using some form of text mark-up, XML-based or otherwise. Currently there is a significant lack of programmer tools for this job. Much of the technology for the visual composition of programs, which has been developed at considerable cost over recent years, seems likely to become unusable in this new environment. There is little or no tool support for the definition syntax of managed dialogue forms and thus this is a job for the experts only.
FIG. 3 shows an abstract of the form definition for a managed dialogue application to perform the same task as the paper form of FIG. 2. Whilst the syntax of this example is not complete or indeed real, it serves as an example of how a managed dialogue application might be defined. There is no “programming” involved simply the definition of the questions to ask the user and the business processes to run when the data is submitted.
An application may be made up of many such forms and there may be complex relationships between the forms allowing for instance, the stock purchase form to inherit the account number value from the authentication or login form. This is a very different way of producing applications.
FIG. 4 illustrates a conceptual overview of the development process. The software developer produces the necessary ideas 400 and creates a set of form definitions 440, based upon these ideas, using the development workstation 410 (ie a text-editor running on the workstation). The definition of the relationships between the forms and between their constituent parts, ie form fields, are manually defined. These are most likely defined in a text mark-up language, XML-based or otherwise, using a basic text editor. The Dialogue Manager 450 then interprets these form definition files. If the system has no NLU functionality, then these form definitions can also define the “look and feel” of the text to be presented to the user. They can contain a number of symbolic references as to how the text should appear (eg links to bitmaps, jpegs etc.).
The process of manually coding the form definition files is not only an extremely arduous task, but the debugging of such applications is currently a very time-consuming and difficult process. It can become near impossible to visualize the complex relationships between the different forms and their constituent part (ie fields) and mistakes are therefore not uncommon.
U.S. Pat. No. 5,784,583, which issued Jul. 21, 1998, relates to a technique by which menus may be created in the form of a visual, tree-like model. Such a technique allows the developer to visualise the overall structure of the menu and hence they are not required to write and compile the code into an application in order to view the menu graphically at runtime. The visual model is then translated into a high level text format which is interpreted in a software application. Conversion of the visual tree into the corresponding menu code is however encapsulated within the development environment.
U.S. Pat. No. 5,651,108, which issued Jul. 22, 1997, discloses a method for creating electronic forms using an object-orientated visual programming language. The form's layout is defined by placing screen objects at desired locations on the canvas. The program logic, which specifies the action taken upon the occurrence of a particular event/input, is attached to the screen objects.
U.S. Pat. No. 5,640,501, which issued Jan. 17, 1997 teaches a method for visually creating and executing goal oriented electronic forms, whereby navigation and completion logic is embedded in the form definition to ensure the operator is only presented with relevant fields. This however is achieved via the invention's own, specially provided tools.
WO9839698, issued Sep. 11, 1998, discloses a method for graphically describing the functionality of a program by generating at least one descriptive diagram. The diagram is then used to further generate a working model of the program by expressing the diagram in an intermediate modelling language. The behaviour of the working model can be quickly and easily changed by modifying the diagrams until the desired result is achieved. Source code is then generated from the object modelling language and compiled to create the final program. This is once again via a specially developed tool. The whole process is encapsulated with the invention's development environment.
Accordingly the invention provides a method for creating a data file using a programming development environment on a computer system, said method comprising the steps of: building a program in said development environment to represent said data file; compiling the program in said development environment into a software executable; and running the executable to generate the data file.
According to the preferred embodiment the program is built by linking a plurality of development components and at least one component comprises characteristic data file information. On running the executable, at least one compiled component outputs its respective data file information into the data file. It does this by creating a file output stream and writing its respective data file information to the output stream. The at least one compiled component also causes another component to output its respective data file information into the data file.
According to the preferred embodiment the development components are Java beans and comprise an icon to permit their representation within visual development tools or environments. The development components comprise a main component, representing a form and a sub-component, representing a text field on the form. The use of a visual development environment to represent the data file means that it is possible to visualise the complex relationships between the various components. The process of creating and debugging the data files is thus a much simpler one.
In the preferred embodiment the program is compiled by generating an executable component from each development component and linking the executable components together. On running a first executable component, data file information from the first executable is output before running the next and subsequent executable components.
The data file itself, according to the preferred embodiment, comprises mark-up information and this may be XML based. A third party computer system interprets this file and this system may be a dialogue management system for a computer telephony system.
In a further aspect the invention provides a system for creating a data file using a programming development environment on a further computer system, said system comprising: means for building a program in said development environment to represent said data file; means for compiling the program in said development environment into a software executable; and means for running the executable to generate the data file.
In a yet still further aspect the invention provides a computer program product comprising computer program code stored on a computer readable storage medium for creating a data file using a programming development environment, said computer program product comprising: means for building a program in said development environment to represent said data file; means for compiling the program in said development environment into a software executable; and means for running the executable to generate the data file.
The invention provides a method of using the existing visual programming tools and environment to automatically generate the textual definitions for the forms. This is more financially sound than making further huge investments in yet another generation of tools.
According to the preferred embodiment, allowing the beans to generate these data files not only isolates the application developer from the syntax of the data files but also in some measure from the actual dialogue management technology being used. By shipping an updated set of beans classes and rerunning the software component it is possible to generate a completely different data file syntax without the need to do anything to the actual application definition. Such isolation allows the dialogue management technology to start simple and to grow over time adding new features and capabilities including even a new definition syntax.